Method for multiplexing data streams onto a transport bearer between an originating network node and a receiving network node

ABSTRACT

The area of the invention belongs to the transport technologies in UTRAN. This invention concerns a method for multiplexing a data stream onto a transport bearer between an originating network node and a receiving network node in a telecommunications network. This is done in order to ensure the effective usage of transport resources over the two interfaces, i.e. Iub/Iur. To accomplish this the RNC and/or Node B/RNC should check if the there already exists a transport bearer, which can be utilised for HS-DSCH transport over Iub/Iur interface. Because of this a transport bearer identification code or transport bearer id is needed to identify this bearer between RNC and Node B/RNC.

[0001] This is a Continuation of International Application No.PCT/FI01/01012 filed Nov. 21, 2001, which designated the U.S. and waspublished under PCT Article 21(2) in English.

FIELD OF THE INVENTION

[0002] The present invention relates to telecommunication systems. Inparticular, the present invention relates to a novel and improved methodfor multiplexing data streams onto a transport bearer between anoriginating network node and a receiving network node.

BACKGROUND OF THE INVENTION

[0003] In the current specifications of the third generation mobilenetworks (referred to as UMTS, Universal Mobile TelecommunicationSystem), the system utilises the same well-known architecture that hasbeen used by all main second generation systems. A block diagram of thesystem architecture of the current UMTS network is presented in FIG. 1.The UMTS network architecture includes the core network (CN), the UMTSterrestrial radio access network (UTRAN), and the user equipment (UE).The core network is further connected to the external networks, i.e. theInternet, PSTN (Public Switched Telephone Network) and/or ISDN(Integrated Digital Services Network).

[0004] The UTRAN architecture consists of several radio networksubsystems (RNS). The RNS is further divided into the radio networkcontroller (RNC) and several base stations (BTS, referred to as Node Bin the 3GPP specifications). In this architecture there are severaldifferent connections between the network elements. The Iu interfaceconnects CN to UTRAN. The Iur interface enables the exchange ofsignalling information and user plane information between two RNCs.There is no equivalent interface to Iur in the architectures of thesecond generation mobile networks. The radio network layer (RNL)signalling protocol across the Iur interface is called the radio networksubsystem application part (RNSAP). The RNSAP is terminated at both endsof the Iur interface by an RNC. The Iub interface connects an RNC and aNode B. The Iub interface allows the RNC to indicate the required radioresources to the Node, for example, to add and delete cells controlledby Node B to support communication of dedicated connection between UEand C-RNC(Control RNC), information used to control the broadcast andpaging channels, and information to be transported on the broadcast andpaging channels. One Node B can serve one or multiple cells. UE isconnected to Node B through the Uu radio interface. UE further consistsof a subscriber identity module (USIM) and mobile equipment (ME). Theyare connected by the Cu interface. Connections to external networks aremade through Gateway MSC (Mobile Services Switching centre) (towardscircuit switched networks) or GGSN [Gateway GPRS (Group Packet RadioSystem) Support Node] (towards packet switched networks).

[0005] The general protocol model for UTRAN Interfaces is depicted inFIG. 2, and described in detail in the following. The structuredescribed is based on the principle that the layers and planes arelogically independent of each other.

[0006] The Protocol Structure consists of two main layers, Radio NetworkLayer and Transport Network Layer (TNL). These are presented in thehorizontal planes of FIG. 2. All UTRAN related issues are visible onlyin the Radio Network Layer, and the Transport Network Layer representsthe standard transport technology that is selected to be used for UTRAN.UTRAN has certain specific requirements for TNL. For instance, the realtime requirement, i.e. the transmission delay has to be controlled andkept small.

[0007] In the HS-DSCH (HS-DSCH, High Speed Downlink Shared Channel;HSDPA High Speed Downlink Packet Access) specification work the basicassumption is that the same transport solution that has been used forDSCH will be used for HS-DSCH also. In this application the term HS-DSCHis used to describe the channel or data stream between CRNC and Node Bon Iub interface and therefore it should not mixed up with the HSDPArelated transport channel, which is an internal channel between MAC-hs(Medium Access Control) and L1 (Layer 1) in Node B. In this solutiondedicated transport bearer is reserved separately for each DSCH datastream between SRNC (Serving RNC) and Node B. FIG. 3 shows the radiointerface protocol architecture with termination points. In logicalmodel MAC-hs, which is inserted in Node B, locates below MAC-c/sh, whichfurther is implemented in CRNC. The HS-DSCH FP (frame protocol) willhandle the data transport from SRNC to CRNC (if the Iur interface isinvolved) and between CRNC and the Node B. The architecture supportsboth FDD (Frequency Division Duplex) and TDD (Time Division Duplex)modes of operation, though in the case of TDD, some details of theassociated signalling for HS-DSCH are different.

[0008] The basic structure of HS-DSCH is assumed to be based on twoarchitectures: an RNC-based architecture consistent with Release '99architecture and a Node B-based architecture for scheduling. Moving thescheduling to the Node B enables a more efficient implementation ofscheduling by allowing the scheduler to work with the most recentchannel information. The scheduler can adapt the modulation to bettermatch the current channel conditions and fading environment. Moreover,the scheduler can exploit the multi-user diversity by scheduling onlythose users in constructive fades. Furthermore, the HSDPA proposal hasthe additional potential to improve on the RNC-based HARQ architecturein both UE memory requirements and transmission delay. The scheduler forthe HS-DSCH is therefore located in the Node B, wherein the HS-DSCHrefers to the transport channel, which locates between MAC-hs and L1internally in Node B.

[0009] There is no identification IE in Iub/Iur FP (FP, Frame Protocol)to identify a certain UE. Therefore the dedicated transport bearers wereneeded to identify a particular UE to enable the efficient usage ofpower control function over the radio interface. This means that numberof required transport bearers to be reserved between SRNC and Node B isthe same as the number of DSCH data streams. One UE can have severaldata streams. To make the system work properly, capacity i.e. bandwidthfor each transport bearer has to be reserved according the reserved DSCHcapacity over the radio interface. E.g. if the DSCH capacity in theradio interface is 512 kbps and there are 10 data streams sharing thechannel the maximum required transport capacity is 10 times 512 kbpsover Iub interface to ensure the QoS. And as the scheduling is done byMAC-sh in CRNC only one transport bearer is used in certain time frame.As a result a lot of bandwidth is wasted. This increases the need of thebandwidth resources.

[0010] The invention is characterised by what is disclosed in theindependent claims.

SUMMARY OF THE INVENTION

[0011] This invention concerns a method for multiplexing a data streamonto one transport bearer between an originating network node and areceiving network node in a telecommunications network. This is done inorder to ensure the effective usage of transport resources over the twointerfaces, i.e. Iub/Iur. To accomplish this the RNC and/or Node B/RNCshould check if the there already exists a transport bearer, which canbe utilised for HS-DSCH data stream over Iub/Iur interface. Because ofthis a transport bearer identification code or transport bearer id isneeded to identify this bearer between RNC and Node B/RNC.

[0012] The scheduling to the radio interface for DSCH is done by MAC-shfunction located in CRNC whereas in the HS-DSCH the scheduling, whereinthe HS-DSCH refers to the transport channel, which locates betweenMAC-hs and L1 internally in Node, B, to the radio interface shall bedone by MAC-hs, which is located in Node B. Therefore the identificationof the transport bearer can be done by other means than using dedicatedtransport bearers between SRNC/CRNC and Node B. Enabling themultiplexing of HS-DSCH data streams to the same transport bearer thehuge amount of transport resources can be saved.

[0013] Before sending any message to Node B/RNC to request a newtransport bearer for HS-DSCH data stream RNC checks if there alreadyexists a transport bearer between RNC and Node B/RNC, which can be usedfor this purpose. If there does not exist any transport bearer,identified by transport bearer id, that can be used to carry a newHS-DSCH data stream, RNC sends the request for a transport bearer forHS-DSCH data stream without transport bearer id to indicate to NodeB/RNC that a new transport bearer is needed.

[0014] If the transport bearer that can be used exists, RNC includes thetransport bearer id to the request message to indicate to Node B/RNCwhich existing transport bearer it likes to use for this new HS-DSCHdata stream. If Node B/RNC accepts the request, no additional transportlayer information shall be included to the response message. OtherwiseNode B/RNC includes a new transport layer information to the replymessage to indicate that the new transport bearer is needed.

[0015] There is also another possibility for Node B/RNC to decide theusage of the transport bearer. In this case RNC will send the HS-DSCHrequest/modification message to Node B/RNC without any furtherinformation. Then receiving Node B/RNC will decide whether it is toassign a new transport bearer or to use existing transport bearer. Incase it decides to assign a new transport bearer, it will reply with newtransport address and new transport bearer id. If it decides to useexisting transport bearer it will reply with only the existing transportbearer id selected to be used as a shared transport bearer for the newHS-DSCH data stream by Node B/RNC, without new transport address.

[0016] In the present specification there is no Id that can be used as atransport bearer id to identify on the Radio Network Layer a certainalready existing transport bearer out of a particular UE context betweenRNC and Node B. It is impossible to indicate to Node B/RNC by RNC thatone of the existing transport bearers can be used to carry another datastream for different or for the same UE.

[0017] To enable the transport bearer selection functionality forHS-DSCH a new transport bearer id shall be introduced between RNC andNode B/RNC in NBAP/RNSAP messages. When a new transport bearer serviceinstance is created, a transport bearer id is assigned to it by the RNLapplication. This transport bearer id needs to be unique at least per aninterface, i.e. between the two UTRAN nodes terminating thecorresponding RNL application protocol. The transport bearer ID isstored by both originating and receiving nodes (RNC, RNC/Node B) for thelifetime of the corresponding transport bearer service instance.

[0018] To ensure the uniqueness of the transport bearer id it could beallocated by either end point of the connection or it could be acombination so that each end allocates a certain part of the identifier:

[0019] In the present invention it is also assumed that the multiplexingof HS-DSCH data streams are provided above transport layer i.e. inFP/MAC layer.

[0020] The benefits of the invention can be summarised as follows: theavailable transport capacity (i.e., bandwidth) is better utilised due tothe improved statistical sharing of the bandwidth. The number oftransport bearers, e.g. AAL2 (ATM Adaptation Layer 2) connection isreduced as one bearer can be shared by several user streams. Thefrequency of transport bearer setups and tear-downs is significantlydecreased as there is no need to have a dedicated bearer for each userstream.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are included to provide afurther understanding of the invention and constitute a part of thisspecification, illustrate embodiments of the invention and together withthe description help to explain the principles of the invention. In thedrawings:

[0022]FIG. 1 is a block diagram illustrating an example of the state ofthe art scenario relating to the present mobile network;

[0023]FIG. 2 is a general protocol model for UTRAN interfaces of FIG. 1;

[0024]FIG. 3 describes a radio interface protocol architecture of HDSPA;

[0025]FIG. 4 is a signalling chart describing one embodiment of thepresent invention; and

[0026]FIG. 5 is a signalling chart describing another embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION

[0027] Reference will now be made in detail to the embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings.

[0028] In FIGS. 4 and 5 is disclosed five network elements. Two of theseelements are named twice, i.e. Node B/DRNC and Node B/SRNC. This namingis done because these two figures are describing only two examples ofthe present invention and these same elements could represent also theother element in the labelling.

[0029] In FIG. 4 is disclosed a signalling chart describing an examplecase wherein Node B decides not to use an existing transport bearerresource. In FIG. 4 Serving Radio Network Controller SRNC decides tosetup a HS-DSCH channel, item 1. After this decision it sends a RadioNetwork Subsystem Application Part (RNSAP,) message requesting RadioLink Setup, item 2. The parameter in this message is [Mux IndicationIE]. This Mux Indication IE can have the following values: “may” or“shall not” in the request message. In case of “may”, receiver candecide whether it will multiplex or not. But in case of “shall not”receiver cannot use multiplex option. The message is sent to Drift RadioNetwork Controller DRNC.

[0030] After this Drift Radio Network Controller DRNC sends a Node BApplication Part message (NBAP) requesting Radio Link Setup to Node B,item 3. The parameter also in this message is [Mux Indication IE]. NodeB then checks if there is available transport bearer for a new RadioLink, item 4. In this case it detects that there exists no suitabletransport bearer and a new transport bearer is needed. Then Node B sendsa Radio Link Setup Response to DRNC to inform DRNC the parameters of thenew transport bearers it has decided to establish. The parameters are[Transport Bearer Id IE, Binding ID IE, Transport Layer Address IE],item 5. Based on the information from Node B, DRNC decides to setup anew transport bearer, item 6. Finally DRNC sends a Radio Link SetupResponse with parameters [Transport Bearer Id IE, Binding ID IE,Transport Layer Address IE] to SRNC.

[0031] In FIG. 5 is disclosed a signalling chart describing an examplecase wherein Node B decides to use an existing transport bearerresource. In FIG. 5 Serving Radio Network Controller SRNC decides tosetup a HS-DSCH channel, item 1. After this decision it sends a RadioNetwork Subsystem Application Part (RNSAP,) message requesting RadioLink Setup, item 2. The message is sent to Drift Radio NetworkController DRNC. The parameter in this message is [Mux Indication IE].This Mux Indication IE can have the following values: “may” or “shallnot” in the request message. In case of “may”, receiver can decidewhether it will multiplex or not. But in case of “shall not” receivercannot use multiplex option. Drift Radio Network Controller DRNC sends aNode B Application Part message (NBAP) requesting Radio Link Setup toNode B, item 3. The parameter also in this message is [Mux IndicationIE]. Node B then checks if there is available transport bearer for a newRadio Link, item 4. In this case it detects that there exists a suitabletransport bearer and no new transport bearer is needed. Then Node Bsends a Radio Link Setup Response to DRNC with parameter [TransportBearer Id IE] informing the existing transport bearer that is to be usedfor this new data stream, item 5. Based on the information from Node B,DRNC decides not to setup a new transport bearer and instead of thatuses an existing transport bearer that has been indicated with transportbearer id, item 6. Finally DRNC sends a Radio Link Setup Response withparameter [Transport Bearer Id IE] to SRNC. This is all what is neededbecause SRNC will use an existing transport bearer and it already hasthe necessary parameters for this bearer.

[0032] The allocating for the transport bearer identification code ortransport bearer id can be done in three ways. An originating RNCallocates the transport bearer id when a new transport bearer forHS-DSCH is needed between RNC and RNC/Node B and includes the transportbearer id to the message requesting HS-DSCH establishment/modification.When receiving node (Node B or DRNC) gets the new transport bearer id itstores it (with other transport layer related information) and returnsthe transport bearer id back to the originating node with allocatedtransport layer information.

[0033] When receiving Node B/RNC gets a Radio Link Setup Request for aHS-DSCH channel from RNC without the transport bearer id, it allocatesthe id and includes it with the transport layer information to replymessage and stores the transport bearer id with correct transport layerinformation.

[0034] In the third option both originating and receiving network nodeallocates a part of the transport bearer id. In this case RNC allocatesthe first part of the transport bearer id when a new transport bearerfor HS-DSCH is needed between RNC and RNC/Node B and includes the partof the transport bearer id to the message requesting HS-DSCHestablishment/modification. After receiving the first part of thetransport bearer id the receiving node allocates the other part of theid and stores the whole transport bearer id (with other transport layerrelated information) and returns the transport bearer id back tooriginating node with allocated transport layer information.

[0035] The transport bearer id is stored in both nodes as long as thetransport bearer it identifies exists.

[0036] It is obvious to a person skilled in the art that with theadvancement of technology, the basic idea of the invention may beimplemented in various ways and in various network environments Theinvention and its embodiments are thus not limited to the examplesdescribed above, instead they may vary within the scope of the claims.

1. A method for multiplexing a data stream onto a transport bearerbetween an originating network node and a receiving network node in atelecommunications network, the method comprising the steps of mapping atransport bearer resource for a data stream, characterised in that themethod further comprises the following steps: checking if there isavailable transport bearer resources in the group of existing transportbearers, and if there exists a transport bearer resource that can beused for said data stream, reserving said existing transport bearerresource for said data stream, or requesting a new transport bearerresource, and reserving said new transport bearer resource for said datastream.
 2. The method according to claim 1, characterised in thatidentifying said new transport bearer resource with a transport beareridentification code.
 3. The method according to claim 2, characterisedin that in said requesting step, indicating an existing transport bearerresource for said data stream by including said transport identificationcode in a request message.
 4. The method according to claim 1,characterised in that in said requesting step, indicating a need for anew transport bearer resource by sending a request message in which notransport identification code is included.
 5. The method according toclaim 2, characterised in that in using a unique transport beareridentification code, said transport bearer identification code beingunique at least between said originating network node and said receivingnetwork node.
 6. The method according to claim 2, characterised in thatrecording said transport bearer identification code at least for alifetime of said transport bearer resource in both said originatingnetwork node and said receiving network node.
 7. The method according toclaim 2, characterised in that allocating said transport identificationcode in said originating network node.
 8. The method according to claim2, characterised in that allocating said transport identification codein said receiving network node.
 9. The method according to claim 2,characterised in that allocating a first part of said transportidentification code in said originating network node and a second partin said receiving network node, said first and second part constitutinga whole transport bearer identification code.
 10. The method accordingto claim 1, characterised in that in said requesting step indicating ifthe multiplexing of said data stream is allowed or not.
 11. A method formultiplexing a data stream onto a transport bearer over the Iur and Iubinterfaces between Serving Radio Network Controller (SRNC) and DriftRadio Network Controller (D-RNC) or Node B in an IP Radio Access Networkmapping a transport bearer resource for a data stream, characterised inthat the method further comprises the following steps: checking if thereis available transport bearer resources in the group of existingtransport bearers, and if there exists a transport bearer resource thatcan be used for said data stream, reserving said existing transportbearer resource for said data stream, or requesting a new transportbearer resource, and reserving said new transport bearer resource forsaid data stream.
 12. The method according to claim 11, characterised inthat identifying said new transport bearer resource with a transportbearer identification code by introducing a new transport bearer idinformation element (IE) in NBAP/RNSAP messages.
 13. The methodaccording to claim 12, characterised in that in said requesting step,indicating an existing transport bearer resource for said data stream byincluding said transport identification code in a request message fromRadio Network Controller or Node B.
 14. The method according to claim11, characterised in that in said requesting step, indicating a need fora new transport bearer resource by sending a request message in which notransport identification code is included.
 15. The method according toclaim 12, characterised in that in using a unique transport beareridentification code, said transport bearer identification code beingunique at least between said Serving Radio Network Controller (SRNC) andsaid Drift Radio Network Controller (D-RNC) or said Node B
 16. Themethod according to claim 12, characterised in that recording saidtransport bearer identification code at least for a lifetime of saidtransport bearer resource in both said Serving Radio Network Controller(SRNC) and said Drift Radio Network Controller (D-RNC) or said Node B.17. The method according to claim 12, characterised in that allocatingsaid transport identification code in said Serving Radio NetworkController (SRNC).
 18. The method according to claim 12, characterisedin that allocating said transport identification code in said DriftRadio Network Controller (D-RNC) or said Node B.
 19. The methodaccording to claim 12, characterised in that allocating a first part ofsaid transport identification code in said Serving Radio NetworkController (SRNC) said Drift Radio Network Controller (D-RNC) or saidNode B.
 20. The method according to claim 1, characterised in that insaid requesting step indicating if the multiplexing of said data streamis allowed or not.